In many implementations of data communications, an application that transmits data does not place its data directly onto the communications link provided by its host computer. Instead, the application passes the data in packets to a high-level protocol driver which manipulates the packets and then passes them down to a low-level driver. The low-level protocol driver may also manipulate the packets before passing them on to a hardware driver which delivers the data to the communications link. This stack of protocol drivers adds delays between when the application requests that data be transmitted and when the data are actually put onto the communications link. Another possible source of transmission delays is the traffic shaper. This protocol driver component tries to ensure that each packet of data is transmitted in a manner that meets the Quality of Service (QoS) requirements of that packet. For example, some packets are only useful if they are transmitted before a specific time. The traffic shaper may allow these time-critical packets to be transmitted while delaying the transmission of any waiting non-time-critical packets. This may delay the transmission of the non-time-critical packets by a second or more.
It may happen during these transmission delays, that the application or a high-level protocol driver decides to cancel the transmission of one or more data packets. For instance, the application may have been shut down or the computer may be rebooting. In these cases, there is no reason to try to transmit the packets. Some operating systems do not provide a mechanism allowing the cancellation of packets pending transmission, however, and before the application can be shut down or the computer rebooted, the pending packets must proceed through the stack of protocol drivers and be sent out onto the communications link. Waiting for the packets to be transmitted causes unnecessary delays just at a time when delays may be unacceptable.
Microsoft's “WINDOWS” operating system provides a mechanism for canceling pending packets. When an application requests that data be transmitted, the request is captured in an Input/Output Request Packet (IRP) which is sent to a high-level protocol driver. The high-level protocol driver translates the IRP into one or more Network Driver Interface Specification (NDIS) packets which are sent down to a low-level protocol driver. While pending IRPs may be canceled, NDIS packets are not currently cancelable. Thus, a request to cancel an IRP waits until all the NDIS packets generated from the IRP complete their transmit processing. This leads to the same result as above: time is spent waiting for the completion of the transmit processing of now meaningless packets.
Some operating systems allow an application or a high-level protocol driver to cancel the transmission of all pending packets. While that may be sufficient in some cases, its inflexibility is inappropriate to other circumstances. For example, an application may be transmitting several logical packet flows across a network. The flows may have different QoS requirements or be sent to different locations. Faced with network congestion, the application or a high-level protocol driver may decide that it is necessary to cancel the transmission of packets in one flow in order to allow packets in the other flows to proceed. Current mechanisms, however, do not allow the selective cancellation of pending transmit packets.